2. Functional View

2.1. Components: Standardized Definition and Scope

OSIA provides seamless interconnection between multiple components part of the identity ecosystem.

The components are defined as follows:

• The Enrolment component. Enrollment is defined as a system to register biographic and biometric data of individuals.

• The Population Registry (PR) component.

  Population registry is defined as “an individualized data system, that is, a mechanism of continuous recording, or of coordinated linkage, of selected information pertaining to each member of the resident population of a country in such a way to provide the possibility of determining up-to-date information concerning the size and characteristics of that population at selected time intervals. The population register is the product of a continuous process, in which notifications of certain events, which may have been recorded originally in different administrative systems, are automatically linked on a current basis. A. method and sources of updating should cover all changes so that the characteristics of individuals in the register remain current. Because of the nature of a population register, its organization, and also its operation, must have a legal basis.” [1]

• The UIN Generator component. UIN generator is defined as a system to generate and manage unique identifiers.

• The Automated Biometric Identification System (ABIS) component. An ABIS is defined as a system to detect the identity of an individual when it is unknown, or to verify the individual’s identity when it is provided, through biometrics.

• The Civil Registry (CR) component.

  Civil registration is defined as “the continuous, permanent, compulsory and universal recording of the occurrence and characteristics of vital events pertaining to the population, as provided through decree or regulation is accordance with the legal requirement in each country. Civil registration is carried out primarily for the purpose of establishing the documents provided by the law.” [2]

• The Document Management System (DMS) component. DMS is defined as a system to manage the production and issuance of physical documents like ID Cards, passports, driving licenses, etc.

• The Third Parties Services component.

Table 2.1 Components

ID Ecosystem Component	Data	Functions
Enrollment	Alpha* UIN* History* Supporting documents*	Recording application Collecting personal data
PR	Alpha UIN History Supporting documents	Identity attributes storage Identity Life cycle management
UIN Gen	Alpha UIN	UIN generation
ABIS	UIN Biometric data (images and templates)	Authentication (1:1) Identification (1:N) Quality control and adjudication
CR	Events UIN History Supporting documents	Events storage Certificate production Workflow
DMS	Alpha UIN History Supporting documents	Document data storage Document Life cycle management Document Production Workflow SMS and email server
Third Parties Services	TBD	KYC/auth

The components are represented on the following diagram:

Fig. 2.1 Components

2.2. Interfaces

To do

This chapter describes the following interfaces.

• UIN management. This interface can be implemented by PR, by CR or by another system. We will consider it is provided by a system called UIN Generator.

• Notifications. When data is changed, a notification is sent and received by systems that registered for this type of events. For instance, PR can register for the events birth emitted by CR.

• Data access. A set of services to access data.

  The design is based on the following assumptions:

  1. All persons recorded in a registry have a UIN. The UIN can be used as a key to access person data for all records.
  2. The registries (civil, population, or other) are considered as centralized systems that are connected. If one registry is architectured in a decentralized way, one of its component must be centralized, connected to the network, and in charge of the exchanges with the other registries.
  3. Since the registries are customized for each business needs, dictionaries must be explicitly defined to describe the attributes, the event types, and the document types. See Data Access for samples of those dictionaries.
  4. The relationship parent/child is not mandatory in the population registry. A population registry implementation may manage this relationship or may ignore it and rely on the civil registry to manage it.
  5. All persons are stored in the population registry. There is no record in the civil registry that is not also in the population registry.

• Biometrics.

• Third party. Identity based services implemented on top of Identity system mainly Identity Verification and Identity Attribute sharing.

2.3. Components vs Interfaces Mapping

The interfaces described in this chapter are summarized in the following table:

Table 2.2 Components vs Interfaces Mapping

	Components
Interfaces	Enroll	PR	UIN gen.	ABIS	CR	ID Card	Funct. Reg	Third Parties
Notifications
Notify event		U			U
Subscribe		U		U	U	U	U
Unsubscribe		U		U	U	U	U
Event callback		I		I	I	I	I
UIN Management
Generate UIN		U	I		U	U
Data Access
Get Person Attributes	U	IU		U	IU	U	U	U
Match Person Attributes		IU			IU	U	U	U
Verify Person Attributes		IU			IU	U	U	U
Get Person UIN	U	IU			IU	U	U
Get document		IU			IU
Biometrics
Verify	U			I		U	U	U
Identify	U			I		U	U	U
Insert		U		I		U
Read		U		I		U	U	U
Update		U		I		U
Delete		U		I		U
Get Gallery		U		I		U	U
Get Gallery content		U		I		U	U
Third Party Services
Verify ID								I
Identify ID								I
Get Attributes								I
Get Attributes set								I

where:

• I is used when a service is implemented (provided) by a component
• U is used when a service is used (consumed) by a component

2.4. Use Cases - How to Use OSIA

Introduction to be done

2.4.1. Birth Use Case

Fig. 2.2 Birth Use Case

1. Checks

   When a request is submitted, the CR may run checks against the data available in the PR using:

   • matchPersonAttributes: to check the exactitude of the parents’ attributes as known in the PR
   • getPersonAttributes: to get missing data about the parents’s identity
   • getPersonUIN: to check if the new born is already known to PR or not

   How the CR will process the request in case of data discrepancy is specific to each CR implementation and not in the scope of this document.

2. Creation

   The birth is registered in the CR. The first step after the checks is to generate a new UIN a call to createUIN.

3. Notification

   As part of the birth registration, it is the responsibility of the CR to notify other systems, including the PR, of this event using:

   • notify: to send a birth along with the new UIN.

   The PR, upon reception of the birth event, will update the identity registry with this new identity using:

   • getPersonAttributes: to get the attributes of interest to the PR for the parents and the new child.

2.4.2. Death Use Case

To be completed

2.4.3. Marriage Use Case

To be completed

2.4.4. Deduplication

During the lifetime of a registry, it is possible that duplicates are detected. This can happen for instance after the addition of biometrics in the system. When a registry considers that two records are actually the same and decides to merge them, a notification must be sent.

Fig. 2.3 Deduplication Use Case

How the target of the notification should react is specific to each subsystem.

2.4.5. ID Card Request

To be completed

2.4.6. Bank account opening Use Case

Fig. 2.4 Bank account opening Use Case

2.4.7. Police identity control Use Cases

Fig. 2.5 Collaborative identity control

Footnotes

[1]	Handbook on Civil Registration and Vital Statistics Systems: Management, Operation and Maintenance, Revision 1, United Nations, New York, 2018, available at: https://unstats.un.org/unsd/demographic-social/Standards-and-Methods/files/Handbooks/crvs/crvs-mgt-E.pdf , para 65.

[2]	Principles and Recommendations for a Vital Statistics System, United Nations publication Sales Number E.13.XVII.10, New York, 2014, paragraph 279